Creating an advanced collaborative open resource network

As part of of the ARPA MADE initiative, we are beginning to develop ACORN, an Advanced Collaborative Open Resource Network, ACORN will provide the infrastructure to create an electronic community which will be able to design and sell engineered products in competitive markets as well as conduct research and development by collaborating through a network. Creating such a community is a task of national proportions and cannot be accomplished by our group alone since the target community encompasses the entire country. We have an unprecedented opportunity to create and experiment with an electronic community which can serve as the model for a larger national community. In this paper, we outline the architecture for an information infrastructure to create and sustain such a community. This paper is not a standard research paper; it is being published to invite the members of the community to participate in the evolution of the ideas expressed here and to encourage the shared development of the infrastructure necessary to create this network. L Introduction This paper describes an open network to provide resources to the design and manufacturing community. As part of the ARPA MADE initiative, we have been funded to begin developing the necessary infrastructure. The ACORN infrastructure must leverage off existing facilities such as the Internet and the research laboratories that have been developed within the community. Whenever possible, we will use tools and services that already exist commercially and in universities. Initially, the ACORN infrastructure will be created as a test bed for designing electro-mechanical devices. A crucial part of creating the ACORN infrastructure is the development of the community that will use and expand the network. Such an electronic community can increase in scale only if the community shares its resources to build continually on the work of each participant, not only for the creation of engineered products but also for the infrastructure itself. The evolution of the infrastructure requires that as software modules arc created they become products and parts in themselves and be used to bootstrap and sustain the infrastructure. Thus the effort expended in the creation of the ACORN infrastructure is expected to produce results that are three fold: 1. a prototype electronic design and manufacturing community 2. a basis for the National Information Infrastructure and 3. a national repository in which engineering designs (including software) can be stored and retrieved for reuse. The creation of such an electronic community in the market place requires a critical mass of participants representing the entire potential user community: industry, government, and universities. In the absence of such a critical mass, the test bed will not grow beyond the universities because the necessary diversity of offerings will be absent. In short, an economically viable electronic community can exist only if each participant perceives advantages to belonging to the community which outweigh the costs as seen from the parochial perspective of purely competitive advantage. The proposed work must therefore draw on a microcosm of the larger community. The lessons learned in its creation and sustenance will serve as the basis for the creation and maintenance of the community which, in turn, can serve as the basis for similar communities focused other interests. The community we envisage can be composed only of voluntary participants. Creating an environment which facilitates such voluntary participation requires considerably more than just generating the necessary hardware and software elements. It requires the careful orchestration of evolving practices, conventions, and standards. These issues must be addressed by one or more bodies that concentrate on the issues that surround any voluntary entity: the basis for entry, the conventions and standards that arc required, the processes for establishing conventions and transforming them into standards, and the systems to ensure the safety, security, and confidentiality of individual interests without jeopardizing the interests of the community. Our community is not monolithic; it is composed of business firms, universities, research establishments, the government, consultants, etc. Each group also has users with widely different technical skills, requirements, facilities, and needs. As such, ACORN must be flexible enough to accommodate the needs and constraints of each potential user. This flexibility requires that the entire effort be based on a compositional approach to systems building where each participant brings their services to both building and creating new applications and work-relationships. This demands that the application services should not be layered; layering would hinder the community's dynamic and ad-hoc composition of working design environments (combination of interaction modes, types of information exchanged etc.) In order to understand the requirements that will drive the architecture of the system, it is important to recognize that ACORN is predicated on organizational and institutional solutions as well as software and hardware solutions. If all aspects are not addressed, ACORN will fail to achieve fully its intended goal of creating flexible design and manufacturing shops based on electronic commerce. Consequently, this technical rationale treats hardware, software, the architecture, the derived procedures, and organizational process all as products of proposed effort. 2. Design Scenario To show the potential benefits of ACORN, we present three scenarios that involve solving the same design problem: first with a geographically co-located design team, then with a geographically distributed team without the ACORN infrastructure, and finally with a geographically distributed team with the ACORN infrastructure. The first two scenarios are examples of certain types of design situations as they occur today. The third is an example of how design might be done once the ACORN infrastructure is in place. Reference is made within the scenarios to software that is being developed by the members of the ACORN team. Although we do not describe the software in this paper, the functions of the software should be clear within the context of the scenario. The first scenario is based on a class design project at CMU. The other two scenarios are variations on the first scenario. 2.1. Co-located Design Team A team of six students from four disciplines is assigned the task of designing and building VuMan 2, a wearable computer with a heads-up display. The project is organized to achieve concurrency in time and resources. The students work together in a single room, so the class operates like an industrial skunk works. The students have access to the expertise and computational tools that are available on campus in much the same way that an industrial team would have access to in-house expertise and tools. Similarly, the students have been given a budget and can use local job shops for tasks such as PCB manufacture. The goal of the VuMan 2 project is to create a prototype of a half pound, belt-mounted computer with a heads-up display. The students must design and build the hardware, software, and mechanical systems in four months. The design is based on a prior, heavier version with less functionality than the specifications for VuMan 2. Figure 1 illustrates the primary tasks and the interactions between the tasks as they evolve over time. Together, the team lays out the expected tasks: create functional specifications for the hardware, software, and mechanical design, assess similar designs and available technologies, synthesize the electronics, design the software and user interface, and design the housing. Because the design team is co-located in close quarters, the members of the team can interact continuously. The need for interaction among subgroups representing various disciplines varies depending on the state of the design. In the beginning, discussions are frequent and intense. As the specifications for each subsystems becomes firmer, the subgroups tend to work among themselves. Each time the systems are integrated, interactions across groups again becomes frequent and intense. Due to time pressure, the students often do not document or record their design decisions. This can lead to problems for absent or new members of the team who will need to be filled in on all the changes and decisions that have been made. Moreover, if design problems arise later in the process, not keeping track of prior negotiations and compromises for how and why certain design threads fit together may make it very difficult to fix problems without causing the threads to unravel. This is especially true when a design is sewn together by groups or team members from different disciplines. Each group spends two or three weeks reading trade magazines and calling vendors to assess the price, capabilities, robustness, and compatibilities of available technologies. As the design progresses, the colocation of the design team allows some (but by no means all) potential problems to be resolved before they became inextricably embedded in a subsystem. For example, when a member of the industrial design team sees a 4" high backplane that the electronic designers are planning on using, he objects that PCB domain PCB manufacture Industrial Housing: design manufacture. _ Electronici domain Mechanical: Software domain domain domain 0) Etec. Designs & Wirewrapy r PCB \ \manufacturej ( PCB route ( Populate \ PCB jc Software \ &UII J Electronics N test J f Housing \ manufacture/